P2841R7 Concept and variable-template template-parameters #7690

burblebee · 2025-02-17T16:58:46Z

[temp.param], [temp.arg.type] Some instructions do not apply due to more recent changes in the wording.
[temp.param] Added a reference for concept-dependent to where it's defined. [temp.constr.concept] Replace "may" with "might" inside note.

Fixes #7657.
Also fixes cplusplus/papers#1546

Notes:

I had several issues with some of the wording - see embedded FIXMEs.
It wasn't clear whether \tcode or math font should be used when formatting some of the invented variables as both appear to be used inconsistently.

cor3ntin · 2025-02-19T08:45:39Z

source/templates.tex

 can be the product of replacing a
 \tcode{>>} token by two consecutive \tcode{>}
 tokens\iref{temp.names}.
 \end{note}

+\pnum
+%FIXME: "is" or "shall be"? i.e., what if it's not?


is. It's a close set. I do agree we never seem to define template parameter, this might be the right place to do it.

Could you send a separate pull request to create such a definition?

source/templates.tex

lprv · 2025-02-20T17:14:15Z

source/templates.tex

+a \grammarterm{template-name} for a template template parameter pack
+\end{itemize}
+designating the $i^\text{th}$ corresponding
+type, template, or constant template argument;


The ordering of the bulleted list is "constant, type, template" but this part follows it up with "type, template, constant". Neither is consistent with the "type, constant, template" ordering that seems to be preferred elsewhere in the text.

lprv · 2025-02-20T17:16:24Z

source/templates.tex

+\item if they declare template template parameters,
+%FIXME: What are "their kinds"? And what does it mean for kinds to be the same?
+%FIXME: We refer to "kinds" in [temp.param]/p2 but never define it.
+their kinds are the same and their \grammarterm{template-head}{s} are equivalent.


This part is redundant with the first item on this list:

Suggested change

their kinds are the same and their \grammarterm{template-head}{s} are equivalent.

their \grammarterm{template-head}{s} are equivalent.

Also, the grammar for concept-tt-parameter does not include a template-head, instead we have "template < template-parameter-list >". The only difference between the two is the optional requires-clause, which (for concept template parameters) would be disallowed by [temp.param]/4 anyway, so we should probably just use "template-head".

source/templates.tex

lprv · 2025-02-20T17:16:37Z

source/templates.tex

-\tcode{TT},
+\tcode{TT} denoting a class template or an alias template,
+a template template argument
+\tcode{VV} denoting a variable template or a concept,


Another instance of inconsistent ordering: here it's "T, TT, VV, i" but subsequent text uses "T, i, TT, VV".

lprv · 2025-02-21T14:53:47Z

source/templates.tex

+each appearance of \tcode{C}{'s} template parameters in
+the parameter mappings of the atomic constraints
+(including concept-dependent constraints)
+in \tcode{CI$'$}


This doesn't make sense to me. Per the previous paragraph, CI' is the normal form of a concept-id whose concept is C, so its parameter mappings shouldn't include any template parameters of C (see [temp.constr.normal]/1.4).

lprv · 2025-02-21T14:53:53Z

source/templates.tex

+The constraint is satisfied if \tcode{CI$''$} is satisfied.
+\begin{note}
+Checking whether \tcode{CI$''$} is satisfied
+can lead to further normalization of concept-dependent constraints.


Suggested change

can lead to further normalization of concept-dependent constraints.

can lead to further satisfaction checking of concept-dependent constraints.

source/templates.tex

lprv · 2025-02-21T14:53:57Z

source/templates.tex

+template <typename T, template<typename> concept CC>
+concept D = CC<T>;
+
+template<typename T,


Suggested change

template<typename T,

template<typename U,

This example deals with parameter mappings of atomic constraints, so using distinct names for template parameters seems preferable.

lprv · 2025-02-21T14:53:59Z

source/templates.tex

+template<typename T,
+         template<typename> concept CT,
+         template<typename, template<typename> concept> concept CU>
+int f() requires CU<T, CT>;


Suggested change

int f() requires CU<T, CT>;

int f() requires CU<U, CT>;

(matching change for the above suggestion)

lprv · 2025-02-21T14:54:25Z

source/templates.tex

+  void g() requires CC<U*, C>;
+\end{codeblock}
+The normal form of the associated constraints of \tcode{f} is
+the concept-dependent constraint \tcode{CT<T, C>}.\\


Suggested change

the concept-dependent constraint \tcode{CT<T, C>}.\\

the concept-dependent constraint \tcode{CT<U*, C>}.\\

lprv · 2025-02-21T14:54:27Z

source/templates.tex

+\end{codeblock}
+The normal form of the associated constraints of \tcode{f} is
+the concept-dependent constraint \tcode{CT<T, C>}.\\
+The normal form of the associated constraints of \tcode{g} is


Suggested change

The normal form of the associated constraints of \tcode{g} is

The the associated constraints of \tcode{g} are

source/templates.tex

lprv · 2025-02-21T14:54:37Z

source/templates.tex

+template<template<typename T> concept X, typename T>
+int f(S<X, T>) requires X<T> { return 43; }             // \#2
+
+f(S<A, int>{});                 // ok, select \#1 because \#2 is not eligible for subsumption


Why "#1" and not "ambiguous"?

lprv · 2025-02-21T14:54:48Z

source/templates.tex

+A synthesized template has the same \grammarterm{template-head} as
+its corresponding template template parameter.
+
+\pnum
 \begin{note}


This note pertains to p3 but these changes place it at the very start of p5, which seems a bit odd.

The paper unfortunately gives rather insufficient editing context. @cor3ntin Please indicate more clearly where new paragraphs are intended to be created. As it is, the fate of the original note is unclear.

burblebee · 2025-02-24T07:31:15Z

@lprv Thanks for your excellent review! I applied some of your suggestions (and might be able to apply a couple more), but several of them are beyond simple editorial fixes, hence outside the scope of applying this motion. Please open issues for these!

Editorial notes: * [temp.param]temp.arg.type] Some instructions do not apply due to more recent changes in the wording. * [temp.param] Added a reference for concept-dependent to where it's defined. * [temp.param] Move reference after "concept-dependent constraint". * [temp.constr.concept] Replace "may" with "might" inside note. * [temp.constr.concept] Add a reference for "normal form". * [temp.func.order] Move note to remain with the relevant context.

This fixes an oversight in the paper.

Thanks for the suggestions. We've applied a few of them, but for matters that are mostly personal preference, please file a separate editorial pull request later.

burblebee marked this pull request as ready for review February 17, 2025 17:16

jensmaurer added this to the post-2025-02 milestone Feb 18, 2025

cor3ntin reviewed Feb 19, 2025

View reviewed changes

lprv suggested changes Feb 20, 2025

View reviewed changes

lprv previously requested changes Feb 21, 2025

View reviewed changes

tkoeppe force-pushed the motions-2025-02-cwg-7 branch 2 times, most recently from 3722ca4 to 745fbf7 Compare March 14, 2025 17:22

burblebee and others added 4 commits March 15, 2025 00:51

[temp.constr.concept] Replace "The constraint" with CD to clarify.

a988822

[temp.constr.concept] Turn "satisfied" into a definition.

da03686

[temp.param] Remove mistaken "opt".

1749957

This fixes an oversight in the paper.

tkoeppe force-pushed the motions-2025-02-cwg-7 branch from 11eabe9 to 1749957 Compare March 15, 2025 00:53

tkoeppe merged commit bb3d30f into main Mar 15, 2025
2 checks passed

jensmaurer deleted the motions-2025-02-cwg-7 branch June 21, 2025 10:14

	their kinds are the same and their \grammarterm{template-head}{s} are equivalent.
	their \grammarterm{template-head}{s} are equivalent.

	can lead to further normalization of concept-dependent constraints.
	can lead to further satisfaction checking of concept-dependent constraints.

	the concept-dependent constraint \tcode{CT<T, C>}.\\
	the concept-dependent constraint \tcode{CT<U*, C>}.\\

	The normal form of the associated constraints of \tcode{g} is
	The the associated constraints of \tcode{g} are

P2841R7 Concept and variable-template template-parameters #7690

P2841R7 Concept and variable-template template-parameters #7690

Uh oh!

Conversation

burblebee commented Feb 17, 2025 • edited by jensmaurer Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lprv Feb 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lprv Feb 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

burblebee commented Feb 24, 2025

Uh oh!

Uh oh!

Uh oh!

burblebee commented Feb 17, 2025 •

edited by jensmaurer

Loading

lprv Feb 21, 2025 •

edited

Loading

lprv Feb 21, 2025 •

edited

Loading